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(54) Routes and patfis management 

(57) The invention provides a new cost-effective 
and efficient framework for network management of tel- 
ecommunications networks by monitoring the network- 
level concepts of routes and paths. The invention is 
emtxxjied in a route and path management (RPM) sys- 
tem which includes a data collector for collecting data 
from the Individual network elements, a management 
server for processing the routing data collected into 
manageable route and path objects and a graphical unit 
tnterfiace (GUI) for allowing a user to manage and mon- 
itor routes and paths in the IP network. By monitoring 
routes and paths, the RPM provides network managers 
with the added capability of troubleshooting, perform- 
ance rrK>nitoring. service level planning and provision- 
ing packet forwarding paths between any source- 
destination endpoints in a network 
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Description 

FIELD OF THE INVENTION 

[0001] The invention relates to network manage- 
ment and in particular, to methods and apparatus for the 
management of routes and paths in telecommunica- 
tions networks. 

BACKGROUND OF THE INVENTION 

[0002] In today's large telecommunications net- 
works such as core networks used tor Internet service 
providers (IMPS) or major corporate backtK)nes, net- 
work management plays an important role in maintain- 
ing network stability, performance and efficiency. 
Network management is used to perform a variety of 
functions including the detection and correction off fault 
conditions, the identification, configuration and monitor- 
ing of use of network devices for cost allocation and per- 
formance evaluation. 

[0003] Presently, the vast majority of networks are 
managed at the physical or device level by a centralized 
management entity commonly referred to as a network 
manager server (hereinafter "network manager") 
whereby devices in the network such as routers and 
physical layer interfaces are each individually polled by 
the network manager for status updates. However, in 
many situations, this process is not time-efficient. 
[0004] For example, in the event of a congestion 
point causing unusual traffic delays or a failure causing 
a traffic inten'uption along a particular routing path, each 
network device located along that particular path and 
involved in the transmission of the traffic delayed or 
interrupted as a result of the congestion point or failure 
must be polled by the network manager to locate the 
source of the problem.' Polling multiple devices each 
time a problem arises along a particular routing path is 
therefore time-consuming and as a lesult, substantially 
lengthens the time necessary to solve the problem. 
[0005] Because polling of multiple network devices 
is time-consuming, most protrfems encountered in a 
network may deteriorate or improve by the time a net- 
work manager is able to track down the root of the prob- 
lem, making it more difficuh to ascertain its true nature. 
Moreover, in n^ny cases, clients only report network 
problems long after their occurrence which, by that time, 
may not be visible problems anymore. This is particu- 
larly true of congestion points which are intermittent by 
their very natijre and only occur in heavy ti^affic condi- 
tions. 

[0006] In ascertainir^ the nature of a particular 
problem, it is often necessary for the network manager 
to determine which clients are affected and the manner 
in which tiiese clients are affected. This typically 
requires a network-level analysis of each problem by 
considering the performance history of the particular 
routes and paths used by each client. A route is a static 



concept typically defined by a source endpoint and a 
destination endpoint in a network. By contrast, a path is 
a dynamic concept associated with a particular route. A 
path is defined as the set of network devices and their 
5 respective interfaces traversed by traffic travelling in a 
particular direction at any given point in time on tiie par- 
ticular route. 

[0007] However, current device-level management 
applications do not provide the necessary tools for effi- 

10 dentiy monitoring routes and paths. As a result, these 
protrfems become virtually impossit)le to solve and may 
persist indefinitely. Therefore, there is a need to provide 
network operators with tiie ability to monitor the per- 
formance history of routes and F>aths for efficient trou- 

15 t>leshooting of problems arising in a network. 

[0008] Another drawback of the use of device-level 
management is that it does not address real-time per- 
formance issues at a routing path level which often arise 
in a network as a result of problems occurring at the 

20 device level such as congestion points and link or equip- 
ment failures. Device-level management only deals with 
performance issues for which the network devices are 
individually responsible. However, this "device-level 
view" does not provide a path-level understanding of the 

25 overall real-time performance of all tiie devices defining 
a particular path of a particular route. 
[0009] For exarrple. in correcting a congestion 
problem, device-level management does not address 
whether the data transmitted on a particular source- 

30 ^destination route follows the intended path which may 
have been specifically provisioned for it or whether it 
has t>een rerouted to an alternate path. 
[001 0] When traffic is rerouted due to a failure in tiie 
' networK another real-time performance issue not 

35 addressed by device-level management is whether tiie 
alternate path chosen has tiie requisite capacity for 
- accommodating the traffic delayed or interrupted or 
whether the traffic as redirected will maintain the same 
lev^ of service it had prior to being redirected. As net- 

40, work routes are currentiy soW to network clients with a 
specific quality of service (QoS), adequate configura- 
tion arxl path provisioning of network routes is becom- 
ing increasingly inrportant. Therefore, there is a need for 
providing a network with adequate real-time perform- 

45 ance monitoring and path provisioning capability for 
maintaining performance in a network and meeting ever 
increasing QoS denrands. 

[001 1 ] The need to deal with device-level problems 
in a more time-efficient ranner and address real-time 

so performance issues arising as a result of the occurrence 
of device-level profcJems has triggered the emergerrce 
of what is now known in network management as trace 
routing. Trace routing applications allow some form of 
network-level management of paths and routes by rely- 

55 ing on test messages to perform patii discovery of spec- 
ified routes. In particular, current trace routing 
inplementations determine the path likely to be followed 
by b^affic for a particular source-destination route by 
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sending one or more test packets from the source node 
to the destination node and summarizing the results. 
However, this method has a number of disadvantages. 
First, the trace routing of any given source-destination 
route can only be performed from the source node. 5 
Another disadvantage is that most network devices are 
not properly instrumented to do this function and do not 
treat the test packets with the same priority than normal 
traffic. Therefore, the results obtained with this method 
are not truly represerrtative of how the network devices w 
handle their respective traffic in real-time. As a result, 
there is a need for an inproved network management 
system for managing and monitoring paths and routes 
in a network and also for monitoring the behaviour of 
network devices in real-time. 75 

SUMf^ARY OF THE INVENTION 

[0012] ft is an object of the invention to obviate or 
mitigate one or more of the above identified disadvan- 20 
tages and shortcomings of current network manage- 
ment applications. . ; , . 
[0013] The invention provides a cost-effective and 
efficient new route and path managemerrt (RPM) frame- 
work for network management of telecommunications 25 
networks by monitoring the network-level concepts of 
routes and paths. By monitoring paths and routes in a 
network, the RPM system provides network managers 
with the added capability of troubleshooting, perform- 
ance monitoring, service level planning and provision- 30 
ing paths between any source-destination errclpoints - 
(routes) in a network. In a preferred embodiment, the 
RPM system is incorporated in an Internet protocol (IP) 
network and is designed to be operable in a simple net- 
work nr^anagement protocol (SNMP) environment. The 35 
RPM system is comprised of a data collector for collect- 
ing routing data from the individual network devices, a 
management server for processing the routing data col- 
lected into manageatrfe route and path objects for trac- 
ing and performance monitoring, a datal>ase for storing 40 
the results and a graphical unit interface (GUI) for allow- 
ing a user to trace routes and paths in the IP network 
and monitor routing performance. 
[0014] By conparison with device-level manage- 
ment applications, the present: invention advarrta- 45 
geously allows . the real-time determination of 
permissible paths having the requisite capability for the 
transmission of data on a given set of routes and routing 
protocols. - 
[001 5] Yet another advantage of the present inven- so 
tion compared to device-level management techniques 
is that it provides means for storing and providing, on t 
demand, route history and path-level multi-metric per-. , 
formance history for future provisioning and trouble- 
shooting of the routes and paths monitored. 55 
[0016] Similarly to current device-level manage- 
ment applications, the invention allows reahtime moni- 
toring and reporting of device-level performance. Yet 
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still another advantage of the present invention over 
device-level management is that it also provides path- 
level real-time and historical performance of routes and 
patfTS monitored. 

[0017] Yet still another advantage of the present 
invention over device-level management techniques is 
that it provides means for raising or clearing quality of 
service {QoS) alarms against routes and patfis moni- 
tored. 

[0018] In another preferred embodiment, the RPM 
system as described atx>ve also has a management 
information base (MIB) in which the route and path 
objects managed by the management server are made 
available to other network entities and applications via 
SNMP 

[0019] Yet still another advantage of the present 
invention is that by using an MIB for SNMP storage of 
the route and path objects managed, the tracing and 
routing performance results generated by the manage- 
ment server may be remotely accessed by any SNMP 
entity. 

[0020] Otiier aspects and features of the present 
invention will become apparent to those ordinarily 
skilled in the art upon review of the following description 
of specific embodiments of the invention in conjunction 
with the accompanying figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0021] Pretended emtKxiiments of the invention wilt 
now be desaibed with reference to the attached draw- 
ings in which: 

. FIG. 1 is a block diagram of an Internet protocol 
V ' network hereinafter the ("IP network"); 

FIG. 2 is a block diagram of a first emlxxjiment of 

tfie route and path management (RPM) system of 

node 1 of the IP network of Rgure 1 ; 

FIG. 3 is a diagram of the graphical user interface of 

the RPM system of Figure 2; 

FIG. 4 is a more detailed block diagram of the RPM 

system of Figure 2; 

FIG. 5 is a block diagram of the path trace & monitor 
; logic unit as implemented in the RPM system of 
, Rgure 4; 

FIG. 6 is a flowchart of the main steps required for 
discovering the paths of a specified route histori- 
cally and in real-time; 

FIG. 7 is a flowchart of the main steps executed by 
. the path trace algorithm used for discovering the 
. paths of a specified route historically and in real- 
time; 

^ * . FIG. 8 is a block diagram of the performance moni- 
tor logic unit, as implemented in the management 

f server of the RPM system of Figure 4 for providing 
real-time performance monitoring of a specified 
? route; . : 

FIG. 9 is a block diagram of the parformance moni- 
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tor logic unit as implemented in the management 
server of the RPM system of Rgure 4 providing his- 
torical performance monitoring of a specified route; 
FIG. 10 is a block diagram of the historical path & 
performance broker as implemented in the man- s 
agement server of the RPM system of Figure 4; and 
FIG. 1 1 is a block diagram of a second embodiment 
of the RPM system of Figure 2. 

DETAILED DESCRIPTION OF THE PREFERRED io 
EMBODIMENTS 

[0022] This invention provides a cost-efficient and 
effective framework for network management of tele- 
communications networks by monitoring the network- is 
level concepts of routes and paths. According to a pre- 
ferred embodiment, the present invention is embodied 
as a route and path nnanagement (RPM) system 
designed to be operable in a simple network manage- 
ment protocol (SNMP) environment. go 
[0023] The RPM system can be incorp>orated in any 
network topology or configuration. For simplicity how- 
ever, the invention will now be described only in relation 
to an Internet protocol network (hereinafter the "IP net- 
work"). This IP network is shown in Figure 1 as 10. 2S 
[0024] The IP network 10 illustrated therein is com- 
posed of a plurality of nodes commonly indicated by 1 1 
and individually numbered 1 through 8. Each of these 
network nodes 1 1 is linked to others of the network 
nodes 1 1 by one or more communication links respec- so 
tively labelled A through L (A-L). Each such communi- 
cation link A-L may be either a permanent connection or 
a selectively enabled (dial-up) connection. Any or all of 
the network nodes 1 1 may be connected to one or more 
edge nodes commonly indicated by 12 for comnmjnica- 35 
Won with other nodes or networks (not shown) located 
outside of the IP network 10. For example, in the IP net- 
work of Figure 1 , nodes 2, 7 and 8 are connected to a 
respective edge node 12. These edge nodes are indi- 
vidually numbered 13, 14, 15. 40 
[0025] TTie network nodes 11 each comprises a 
data processing system (not shown) which provides 
data communications servk;es to all connected nodes, 
network nodes 1 1 and edge nodes 12, as well as pro- 
viding decision units (not shown) within the node 1 1 . At 45 
each network node 11, the decision units present 
therein serve to selectively route incoming data packets 
on one or more of the outgoing communication links A- 
L for transmission to other nodes 1 1 or edge nodes 12. 
Such routing decisions are made in response to infer- so 
mation in the header of each data packet received. 
[0026] In the IP network 10, the overall manage- : 
ment of the IP network 10 of Rgure 1 is performed by a " 
centralized network management system which can be 
found in or attached to any one of the network nodes 11 S5 
shown in Figure 1. For darrty. the network management 
system will now be described below as being part of 
node 1 in reference to Figures 2 through 9 and as such. 



node 1 is hereinafter refen-ed to as the onetwork man- 
agera. However, it is to be understood that the network 
management system could alternatively be imple- 
mented in any other node 1 1 of the IP network 10 or in 
the further alternative, implemented in multiple nodes 
11 of the IP network 10. 

[0027] In the IP network 10 of Rgure 1 , the network 
manager 1 is responsible for executing management 
applications such as the integrated network manage- 
ment (INM) application for monitoring and controlling 
network elements or NEs. Network elements are 
devices such as the edge nodes 12, network nodes 1 1 
and their associated rojters and interfaces. In order to 
be managed by the network manager 1 , these network 
elements are each assigned to a management agent 
responsible for performing the network management 
functions requested by the network manager 1 . 
[0028] As is well krrown, the agents are responsible 
for accessing information about the network elements 
assigned to them and make it available to the network 
manager 1. For example, an agent might report the 
number of bytes arxi packets in and out of a particular 
network element, or the nurrU>er of messages sent and 
received by that network element during a given tinne 
period. These variables are referred to as managed 
objects and are ntaintained in a datat^se referred to as 
a management information base (MIB) unique to each 
network elennent. Therefore, when the network man- 
ager 1 requests infornnation relating to a particular ele- 
ment of the IP network 10. that information Is obtained 
from the associated MIB via the agent assigned to the 
F)articular network element In the following description 
of the IP network 10, the MIBs and associated agents 
are not always referenced specifically. However, it Is to 
be understood that by referring to the network elements, 
reference to the associated MIBs and agents is implied. 
[0029] As noted above, the RPM system 20 of tiie 
IP network 10 is implemented to be operable in an 
SNMP environment. Although not essential to tiiis 
invention, the SNMP implementation is highly desirable 
for. promoting interoperability and facilitate tiie 
exchange of management information between the net- 
work manager 1 and tiie agents of the respective net- 
work elements. 

[0030] Referring now to Figure 2, the network man- 
ager 1 is provided with the RPM system 20 which pro- 
vides the functionality required for troubleshooting, 
performance monitoring, service level planning and pro- 
visioning of patiis and/or network elements for any 
source-destination route in the IP network 10. The RPM 
system 20 is comprised oi a management server 22 for 
providing the RPM functionality described above which 
is connected to an external datat>ase 25. Tlie RPM sys- 
tem 20 also has a standard SNMP data collector (here- 
inafter simply refen-ed to as "data collector") 21 
connected to tiie management server 22 which is 
responsible for handling SNMP communications 
between the management server 22 and the network 
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elements of the IP network 10, and a graphical user 
interface (GUI) 23 connected to the management server 
22 for allowing a user to readily access and make use of 
the RPM functionality for managing the IP network 10 at 
a network level. 

[0031] According to a preferred embodiment, the 
RPM system 20 is incorporated in the network manager 
1 as an add-on to the device-level network management 
functionality provided by a well-known standard network 
management application referred to as integrated net- 
work management (INM) 26. As such, for the RPM sys- 
tem 20 description provided below, it is to be assumed 
that the RPM system 20 is designed to be launched 
from INM 26. It is to be understood that the RPM system 
could alternatively be designed as an add-on to other 
network management applications or in the further 
alternative, as a stand-alone network management 
application. The specific steps required to implement 
the RPM system 20 as a stand-alone network manage- 
ment application or the steps to integrate the RPM sys- 
tem 20 into INM 26 or any other network management 
application would be obvious to a person skilled in the 
art and. as such, is not described here in any detail. 
[0032] Referrir^g now to Figure 3. there is illustrated 
the GUI 23 used according to the preferred embodiment 
of this invention to enable a GUI user to specify and 
monitor routes, paths and associated network ele- 
ments. When operational, the GUI 23 produces a main 
computer window which is subcfivided into 5: sections. 
More specifically, sections 30, 31. 32 of the main com- 
puter window are located on the left harrd side of the 
main computer window to form a left handed pane while 
sections 4 and 5 are located on the right hand side of 
the main window forming a right handed pane. 
[0033] Sections 30, 31, 32 of the left handed pane 
each contains a respective table. In. particular, section 
30 contains a table which can be used by the GUI user 
to specify the routes to be monitored (hereinafter the 
"route table"). In. order to specify a particular route., the 
route table of section 30 contains 3 column fields in 
which a GUI user can enter the parameters associated 
with that route. More specifically, the first column field 
corresponds to the route name, the second column field 
conresponds to the route source IP and the third column 
field corresponds to the route destination IP. 
[0034] Section 31 contains a table (hereinafter the 
"path table") for displaying the paths associated with a 
particular route when the route is selected in the route 
table 30 by the GUI user. The path tat)!e 31 contains a 
path colour column and a path name column for identi- 
fying each path of the selected route with a particular 
colour and name. . , 

[0035] Section 32 contains a table (hereinafter the 
"path instance table") for displaying the p^ths instances 
associated with a particular path when the path is 
selected in the path table 31 by the GUI.user. Each path 
instance provides the paranielers of a particular path for 
a given time. The path instance table 32 contains 5 col- 
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umn fields for the following path attributes: (1) time 
stamp. (2) path direction. (3) percentage of utilization. 
(4) errors and discards and (5) latency. 
[0036] Sections 33 and 34 of the right handed pane 

5 each contains a respective notepad for graphically dis- 
playing RPM results corresponding to the routes and 
paths specified in tables 30. 31 and 32. 
[0037] In particular, section 33 contains a notepad 
for graphically displaying the nodes, interfaces and links 

10 of the routes and paths selected in tables 30. 31 and 32. 
The rrotepad of section 33 has 3 display modes, namely 
a linear graphics mode, a route network graphics mode 
and a network graphics nxxje. These nrxxles are selec- 
tively enabled by way of a respective pull-down menu 

15 located in a top portion of section 33. 

[0038] In the linear graphics mode, the selected 
route and its associated paths, nodes and interfaces are 
shown in the notepad of section 33 on a straight line 
without regard to the actual layout of the IP network 10. 

20 Based on the parameters specified in tables 30, 31 . 32. 
three display scenarios are possible. Rrst when a route 
is selected in the route table 30. only the source and 
destination nodes are shown in the notepad of section 
33. Secondly, when a path of a particular route specified 

25 in the route table 30 is selected in the path tat»le 31 . all 
the nodes and interfaces associated with the path 
selected are shown on a straight line in addition to the 
source and destination nodes. Thirdly, when a path 
instance of a particular path selected in the path table 

30 31 is selected in the path instance table 32. all the 
nodes and interfaces of the forward path are shown on 
a top straight line and all the nodes and interfaces of the 
backward path are shown on a bottom straight line 
below the forward path. 

35 [0039] In the route network graphics mode, the 
selected route and its associated paths, nodes and 
Jnterfaces are shown in the notepad of section 33 where 
. the nodes and interfaces are displayed as positioned in 
the IP network 10. In other words, the location of the 

40 nodes and interfaces as displayed in the notepad of 
section 33 is representative of their actual location in the 
. IP network 10. 
[0040] In the network graphics nxxle. the paths, 
nodes and interfaces of all the routes specified in the 

45 . route table 30 are displayed in the notepad of section 33 
in the same manner the selected route and its associ- 
ated paths, nodes and interfaces are shown in the route 
network graphics mode i.e. the rxxles and interfaces are 
displayed as positioned in the IP network 1 0. 

50 [0041] Section 34 of the right handed pane also 
contains a notepad for. graphically displaying real-time 
arxJ history performance charts for any one of the 
routes specified in the route table 30 or any. one of its 
^ associated paths., nodes or interfaces. 

55 [0042] According to the preferred enrdxxliment of 
the invention, the GUI 23 is designed to allow the GUI 
user to specify the rate at which the selected route and 
; , paths are to be monitored. The monitoring rate is 
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defined by the rate at which the network elements are 
polled by the management server 22 (see below) which 
corresponds to the rate at which the information in the 
GUI 23 is to be updated. This rate is hereinafter referred 
to as the polling rate and for the GUI 23 of the present 
invention, this rate is set to 10 minutes. 
[0043] In operation, the tables 30. 31, 32 and the 
section 33 and 34 notepads are empty. In order to spec- 
ify a particular route, the GUI user enters the parame- 
ters associated with that route in the route table 30 and 
in particular, the route name, the route source IP arrd 
the route destination IP. As the GUI user wishes to mon- 
itor more routes, these routes can also be specified in 
the route tatrfe 30 by entering their respective route 
parameters i.e. the route name, the route source IP and 
the route destination IP. 

[0044] Once the desired routes have been specified 
into the route table 30, each particular route contained 
therein may then be selectively monitored at the rate 
specified by the monitoring rate (see above). In order to 
monitor a particular route, the route must first be 
selected (highlighted) in the route table 30. As this 
occurs, all the paths associated with that particular 
route will appear in the path table 31. When a path is 
selected among the paths contained in the path table 
31, all of the instances of the selected path will be dis- 
played in the path instance table 32. As a result, each 
path instance of the selected path will be displayed 
showing the parameters of the selected path for specific 
times. The notepads in sections 33 and 34 can t»e used 
thereafter for monitoring the performance and path 
changes of the path instances listed in the path Instance 
table 32. 

[(M>45] Referring now to Figure 4. there is illustrated 
a more detailed block diagram of the RPM system 20 of 
Figure 2. Briefly stated, the RPM system 20 provides 
real-time and historical tracing of routes and paths 
specified by a user through the GUI 23 as well as real- 
time and historical performance monitoring of the routes 
and paths specified. This route tracing and performance 
monitoring functionality is errtoodied in the manage- 
ment server 22 to provide the network manager 1 with 
the added capak^'iity of trout^leshooting, performance 
monitoring, service level planning and provisioning 
paths between any source-destination endpoints 
(routes) in the IP network 10 of Rgure 1. 
[0046] In order to carry-out the above-mentioned 
functionality, the management server 22 is comprised of 
a path trace & monitoring logic (T&ML) unit 41 for the 
real-time and historical tracing of a specified route, a 
performance monitCMing logic (ML) unit 42 for nrx^nrtor- 
ing the performance of the paths associated with a' 
specified route and a historical path & performance bro- 
ker 43 for analysing past trace and performance results.. 
The management also has a collector interface (com- 
munication layer) 40, a database (DB) manager 46, a 
request dispatcher 45. a server remote method Invoca- 
tion (RMI) irnerface 47 and a notification channel 44 all 



interconnected witii the path T&ML unit 41, the path & 
performance broker 43 and the performance ML unit 42 
in the following manner. The collector interface 40 is 
externally connected to the data collector 21 through an 

5 RMI interface 50 and internally connected to both the 
path T&ML unit 41 and the performance ML unit 42. The 
path T&ML unit 41 is connected to the performance ML 
unit 42 and also to the notification channel 44. The noti- 
fication channel 44 is externally connected to the GUI 

10 23 via the RMI 48 intemal to the GUI 23. The perform- 
ance ML unit 42 is also connected to the notification 
channel 44 and to the DB manager 46 providing con- 
nectivity with the database 25 external to the manage- 
ment server 22. The management server 22 also has 

75 the request dispatcher 45 connected to receive 
requests from the GUI 23 via the server RMI 47 internal 
to the management server 22. The request dispatcher 
45 is connected to the DB manager 46. the path T&ML 
unit 41 , the historical path & performance broker 43 and 

20 the performance ML unit 42. 

[0047] The following section will now describe in 
detail and in reference to Figures 5 through 1 0 the oper- 
ation of the management server 22 in terms of the archi- 
tecture and functionality of each of its path T&ML unit 

25 41. historical path & performance broker 43 and per- 
formance ML unit 42. 

[0048] Referring firstly to Figure 5. the RPM system 
20 is shown with a more detailed block diagram of the 
path T&ML unit 41 as implemented in the management 

30 server 22 for providing real-time arKi historical tracing of 
a specified route. In particular, the path T&ML unit 41 is 
comprised of a path trace harxiler 55, a source and des- 
tination register 56, a path objects assembler 57, a "get 
next hop" logic trfock 58. a queuing manager 60. and a 

35 path change monitor logic 59 all interconnected within 
the n^anagement server 22 as follows. The path trace 
handler 55 is connected to the request dispatcher 45 
and to the DB manager 46. The source and destination 
register 56 Is connected to the queuing manager 60 and 

40 to the path objects assembler 57. The path objects 
assembler 57 is, in turn, connected to the get next hop 
logic 58 and the path change monitor logic 59. The path 
. change monitor logic 59 is coupled to the DB manager 
46, the notification channel 44. the performance ML unit 

45 42 arKi the get next hop logic 58. The get next hop fogic 
58 is externally connected to the data collector 21 via 
the collector interface 40. 

[0049] The real-time tracing operation of the man- 
agement server 22 is triggered when the user requests, 

50 through the GUI 23. that a particular route be traced in 
real-time. The request dispatcher 45 receives the user's 
' request and places it into the path trace harKjIer 55. The 
path trace handler 55 operates to separate the route 
tracing request into its constituent source and destina- 

55 tion endpoint components and subsequently forwards 
tiiem to the DB manager 46. Upon receipt, the DB man- 
ager 46 requests from the database 25 all tiie associ- 
ated source and destination objects (interfaces) for the 
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source and destination endpoint components of the 
specified route. 

[0050] Once captured from the database 25, the DB 
manager 46 places the source and destination objects 
into the queuing manager 60 which is responsible for 
queuing and processing route tracing requests accord- 
ing to a high priority, a real-time priority, a historical high 
priority or a historical low priority. For a real-time trace 
routing request, tiie DB manager 46 places the source 
and destination objects of the route specified by the 
user into the queuing manager's real-time queue for 
processing. When the queuing manager samples the 
real-time queue, it then draws the source and destina- 
tion objects associated with the specified route and 
sends them into the source and destination register 56 
for furtiier processing. 

[0051] For each of the source endpoint and inter- 
mediate points located between the source endpoint 
and the destination endpoint; the path objects assem- 
bler 57 asks the get next hop logic 58 (further details 
below) to find the next hop to the destination endpoint 
until it actually hits the destination endpoint. This results 
in tiie discovery (assembly) of all the paths used in real- 
time by traffic being transmitted on the specified route 
from the source endpoint to the destination endpoint. 
each path being defined as a manageable object con- 
taining a respective set of network devices and associ- 
ated interfaces located t>etween the source endpoint 
and the destination endpoint of the specified route. 
These paths are hereinafter referred to as lorward 
paths". This path discovery process is repeated for 
assemWing the paths used for transmitting traffic from 
the destination erxJpoint to the source endpoint (herein- 
after referred to as l>ackward paths'^- > ^ 
[0052] For each forward and backward path assem- 
bled, the path objects assembler 57 places the corre- 
sponding constituent network devices and associated 
interfaces into a respective path tist for notification t>ack 
to the user which can then access this information via 
the GUI 23 (see at>ove). The path objects assembler 57 
also operates to temporarily store the results of the 
paths discovered into the datatjase 25 through the DB 
manager 46 in order to save the results of the real-time 
tracing operation for real-time performance analysis. 
The patii objects assembler 57 then informs the per- 
formance ML unit 42 to begin sending real-time per- 
formance data back to the user through the GUI 23- 
(further details below). 

[0053] As routing in a network is dynamic, the paths 
discovered for the route specified are monitored period- 
ically by the path , change monitor logic 59 for path 
changes. In particular, the paths are rediscovered and 
checked against the existing paths at the polling rate 
specified by the user in tiie GUI 23. ff tiie rediscovered 
patiis differ from the existing paths in any way (by a sin- 
gle network device or a single interface), this causes the 
paths to be updated or new paths to be associated with 
the specified rout . If there is-any path changes, an 



alarm is generated by tiie patti change monitor logic 59 
for the GUI user through the notification channel 23. 
[0054] There may be situations where patii 
changes occur between polling events which are worthy 

5 of notification to the GUI user. To address tiiese situa- 
tions, the RPM system 20 is designed with tiie ability to 
handle traps generated by network elements 24 and 
notify the GUI user of signif rcant events. 
[0055] Traps generated by network elements 24 are 

10 received into the management server 22 ttirough a trap 
gatherer 61 which is preferably implemented in the data 
collector 21. The trap gatiierer 61 fonvards each ti^ap 
received to a trap handler 62 which is internal to the 
management server 22: Upon receiving a trap from a 

15 particular network element 24, the trap handler 62 
requests tiiat all paths associated with that particular 
network element 24 be placed into the high priority 
queue for processing so that the GUI user can be noti- 
fied of the changes. 

20 [0056] In order to trigger the historical tracing oper- 
: ation of the management server 22. the user has to 
request, through the GUI 23, that a F>articular route be 
monitored so that the results of the tracing operation be 
saved permanentiy in the database 25 for subsequent 

25 historical analysis. Similarly to the real-time tracing 
operation of the management server 22. the user's his- 
torical route trace request is received in the request dis- 
patcher 45 which places it into the path trace handier 
55. The path trace handler 55 operates to separate the 

30 historical ti-ace route request into its constituent source 
and destination endpoint conrponents and sut)se- 
quently forwards tiiem to the DB manager 46. Sinrdlarty 
to the manner in which a real-time route trace request is 
processed, the DB manager 46 then requests and cap- 

35 . tures from the database all the associated source and 
. destination objects (interlaces) for the source and desti- 
. nation endpoint components of the specified route and 
registers each object pair as a historical monitored 
. route into a route list maintained in tiie ctetat>ase 25 for- 

40 all historical monitored routes. 
, [0057] In order to service the user's historical route 
trace request, the queuing .manager 60 periodically 
requests tiiat the DB manager 46 provides it with a list 
of all source and destination object pairs stored in the 

45 . route list of the database 25 and places them in its low 
priority queue. The queuing manager 60 will then 
' sequentially send, in accordance with its d^ined priority 
levels, the low priority object pairs queued to the source 

. . and destination register 56 for processing and subse- 

50 quent forwarding to the path assemtDler 57. The path 
objects assembler 57 operates in the same manner it 
operates when assembling (discovering) paths in 
response to a real-time route trace request. Accordingly, 
in tiiis case, the path objects assembler 57 operates to 

55 . assemble all of the forward and backward paths associ- 
ated with the route specified, requests that the patti 
change monitor logic 59 nrtonltor the patiis discovered at 
the polling rate and notify the user via the notification 
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channel 44 of any path changes observed as a result of 
a new poll or a trap received from the IP network 10, 
[0058] However, in contrast to real-time operations, 
the path objects assembler 57 op>erates to permanently 
store the results of the paths discovered into the data- 
base 25 through the DB manager 46 in order to save the 
results of the historical tracing operation. By serxjing an 
appropriate request to the management server 22, the 
GUI user can then obtain the historical information 
stored for subsequent historical performance analysis. 
[0059] To further explain the real-time and historical 
tracing operation of the management server 22, a flow- 
chart is shown in Figure 6 illustrating the main steps 
performed by the management server 22 in servicing a 
real-time or historical route tracing request for discover- 
ing the paths of the route specified. From this flowchart, 
it can be observed that the tracing operation of a partic- 
ular route is triggered by the user which specifies the 
source and destination endpoints of the route. It can 
also be observed that if historical monitoring is per- 
formed, the source and destination endpoints of the 
specified route are permanently saved in the database 
25 (Figure 5) for subsequent historical analysis. It can 
still be further observed that for each of the source end- 
point and intermediate points located between the 
source endpoint and the destination endpoint which are 
traversed by traffic travelling from the source endpoint 
and the destination endpoint, all the associated forward 
paths are discovered. It can still be further observed that 
this path discovery process is repeated for the back- 
ward paths associated with the particular route speci- 
fied. 

[0060] As noted above in reference to Figure 5, the 
fonward paths and backward paths are assembled by 
running a path trace algorithm. This particular algorithm 
is run by the get next hop logic 58 of Figure 5 which, for 
the source erxlpoint or any of the intermediate points 
located between the source endpoint and the destina- 
tion erK#x>int, operates to find. the next intermediate 
point (hop) to the destination endpoint until it actually 
hits the destination endpoint. This involves sequencing 
through each intermediate point located between the 
source enctx>int and the destination endpoint of the 
specified route and gathering routing and interface 
information specific to each intermediate point The 
information gathered is then processed by the path 
oyects assemtjier 57 (see Figure 5) for assembling the 
paths associated to the specified route. 
[0061] To further describe this, reference is now 
made to Figure 7 which contains a flowchart of the 
sequencing operation of the path trace algorithm 
referred to above. From, this flowchart, it can be 
obsen/ed that based on the particular source endpoint 
specified by the GUI user, the path trace algorithm ini- 
tially runs a device discovery routine for gathering Iden- 
tification information about that particular source 
endpoint Next, an interface discovery routine is run for 
determining the input interface associated with the par- 



ticular source point specified. Next, the path trace algo- 
rithm runs a routing information discovery routine for 
obtaining information about the manner in which the 
source endpoint routes traffic intended for the destina- 

5 tion endpoint. Next, the path trace algorithm runs a get 
next hop discovery routine to firKi the next hop in the 
path to the destination endpoint which is followed by a 
leave interface discovery routine run to determine the 
particular output interface associated with the source 

10 endpoint. Next, the next hop is compared to the destina- 
tion en4>oint supplied by tiie GUI user and if the next 
hop is the destination endpoint a path to the destination 
endpoint Is found and reported to the path objects 
asserrtDler 57. If the next hop is not the destination end- 

75 point, then the next hop is fed back into the patii ti^ace 
algorithm which runs again for determining the next hop 
in the path to the destination endpoint. This process is 
repeated until the next hop becomes the destination 
endpoint at which time, as noted above, the path found 

20 is reported to the path objects assembler 57 (Figure 5). 
[0062] Referring now to Rgure 8. there is illustrated 
a more detailed block diagram of the performance ML 
unit 42 of Figure 4 as implemented In the management 
server 22 for providing real-time performance monitor- 

25 ing of a specified route. 

[0063] The performance ML unit 42 is comprised of 
a nrK>nitoring queue 65 externally connected to both the 
request dispatcher 45 and the DB manager 46 and 
. internally connected to a route queue 66, a path queue 

30 67 and an object queue 68. These queues 66, 67, 68 
are respectively used: for holding identification data 
related to routes, patiis and associated objects (network 
devices, interfaces, etc.) which is periodically updated 
from the database' 25 each time a real-time perform- 

35 ance monitoring request comes in from tiie request dis- 
patcher 45 (further details below). The route, path and 
; object queues 66, 67. 68 are respectively connected to 
a. corresponding route, path and object performance 
logic unit 70, 71 69. The object performance logic unit 

40 69 is externally connected to the data collector 21 
tiirough the communication layer 40 and also internalty 
connected in series to the path and the route perform- 
• ance logic units 70. 71. Finally, eadi of the route, patii 
and object performance logic units 71 , 70. 69 is exter- 

45 nally connected to the notification channel 44. 

[0064] According to the preferred embodiment of 
the present invention, the real-time performance moni- 
toring operation of tiie management server 22 is trig- 
gered as the user requests, through the GUI 23, that the 

50 performance of a particular route be monitored in real- 
' time. This usually occurs after the specified route has 
. been traced in real-time when the path objects assem- 
bler 57 of the path T&ML unit 41 (see Figure 5) requests 
the performance ML unit 42 to begin sending real-time 

55 performance data bacU to the user through the GUI 23. 
[0065] When such a request is Initiated, it Is 
received in the monitoring queue 65 which, as a result, 
proceeds to iqxJate the information contained in each of . 
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the route, path and objects queues 66, 67. 68 with new 
identification data which was previously temporarily 
stored in the database 25 by the path objects assembler 
57 (Figure 5) in executing the associated request for 
real-time tracing of the route specified. This new identi- 
fication data is added to the existing (old) identification 
data contained the corresponding queue 66. 67. 68. 
The object performance logic 69 begins polling each 
network otDject listed in the object queue 68 (new and 
old) through the data collector 21 to obtain performance 
data for each of the objects listed. The object perform- 
ance logic 69 then forwards the polled responses 
obtained to the notification channel for notification to the 
GUI 23. 

[0066] The polled responses are also sent to the 
path performance logic 70 together with the polled 
objects where the objects polled are compared to 
threshold data contained in the path queue 67 and per- 
formance for each of the paths listed therein is calcu- 
lated. The path performance logic 70 will then notify the 
route performance logic 71 that it has completed the 
path performance analysis for the particular objects 
polled and for>vard its performance results to the notifi- 
cation channel 44 for transmission to the GUI 23. The 
path performance logic 70 also proceeds to forward its 
performance results together with the paths for. which 
performance was calculated to the route performance 
logic 71 which compares the paths obtained from the 
path performance logic 70 with the old identification 
data contained In the route queue 66 and calculates an 
overall route performance metric which is then transmit- 
ted to the GUI 23 through the notification channel 44. 
The real-time monitoring operation of. the management 
server 22 just described above is repeated at the polling 
rate specified by the user through the GUI 23. 
[0067] Refen'ing now to Figure 9, there is illustrated 
a nrrare detailed block diagram of the performance; ML 
unit 42 of Figure 4 as implemented in the management 
server 22 for providing historical performance monitor- 
ing of a specified route. The route queue 66. a path 
queue 67 and object queue 68 descrit>ed above are 
also used by the performance ML unit 42 for historically 
monitoring the performance of a specified route. It will 
be recalled that the queues 66, 67, 67 are respectively 
used for holding identification data related to routes, 
paths and associated objects (network devices, inter- 
faces, etc.). As will be described below, this identifica- 
tion data is periodically updated frorn the database 25. 
The route, path and object queues 66, 67, .68 are 
respectively connected to a corresponding route, path 
and object performarrce monitor logic 74, .73, 72. The 
object performance monitor logic unit 72 is externally 
connected to the data, collector 21 through the commu- 
nication layer 40 and also internally connected in series 
to the path and the route perfamance monitor logics 73, - 
74. Finally, each of the route, path and object perform- 
ance monitor logics 74. 73, 72 is externally connected to 
the notification channel 44. 



[0068] The historical performance monitoring oper- 
ation of the management server 22 is initially triggered 
by a request from the user, through the GUI 23. that the 
performance of a particular route be historically moni- 

5 tored. Upon b>eing requested to initiate historical per- 
formance monitoring of a specified route, the historical 
performance ML unit 42 polls the associated objects 
through the data collector 21 , computes the perform- 
ance of each of the objects polled and with these 

10 results, computes the performance of each path associ- 
ated with the specified route and again with these 
results, computes the performance of the specified 
route itself. All of these performance results are perma- 
nently saved in the database 25 for subsequent histori- 

15 . cal analysis. 

[0069] More spedftcally, when a historical perform- 
ance monitoring request is initiated, it is received in the 
monitoring queue 65 which, as a result, proceeds to 
update the information contained in each of the route, 

20 path and objects queues 66, 67. 68 with new identifica- 
tion data which was previously permanently stored in 
the database 25 by the path objects assembler 57 in 
executing the associated request for historical tracing of 
the route specified. This new identification data is added 

25 to the existing (old) identification data contained the cor- 
resporxiing queue 66. 67, 68. 

[0070] The object performance monitor logic 72 
begins polling each network object listed in the object 
queue 68 (new and okfl through the data collector 21 to-^ 
30 obtain performance data for each of the objects listed. ^ 
The object performance monitor logic 72 then forwards 
the polled responses obtained from the data collector 
. 21 to the notification channel for notification to the GUI t 
23. The polled responses are also sent to the path per- 
35 formance monitor logo 73 together with the polled" 
objects where the objects polled are compared to the^ 
old identification data contained in the path queue 67 
and performance for each of the active paths listed 
therein is calculated. The path performance monitor 
'40 logic 73 will then notify the route performance monitor 
logic 74 that it has completed the path performance 
analysis for the particular objects polled and fonward its 
: . performance results to the notification channel 44 for 

. transmfesion to the GUI 23. 
45 . (0071] TTie path performance monitor logic 73 also ; 
proceeds to forward its performance results together 
v/ith the paths for which performance was calculated to 
c the route performance monitor logic 74 which compares 
the paths obtained from the path performance logic 73 
50 with the old identification data contained in the route 
queue 66 and calculates an overall route performarrce 
. J metric which is then transmitted to the GUI 23 through 
the notification channel 44. 
r [0072] The performance of the specified route and 
55 each of the associated paths and objects is also meas- 
, "ured against appropriate performance thresholds 
located in tiie threshold crossing logic 75. If any per- 
formance threshold is breached for any of tiie objects, 
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paths or the specified route itself, the user is notified 
through the notification channel 44. Once the threshold 
calculations have been completed, the historical per- 
formance monitoring process described above is car- 
ried out again to obtain new performance values which 5 
are also permanently stored in the database and 
checked against appropriate performance thresholds. 
The historical performance monitoring process is 
repeated until terminated by the user via the GUI 23. 
[0073] Refen-ing now to Figure 10. the historical 10 
path & performance broker 43 as implemented in the 
management server 22 allows the user to retrieve the 
historical route and paiormance data respectively col- 
lected and permanently stored in the database 25 as a 
result of carrying out historical route trace requests and is 
historical performance monitoring requests. 
[0074] The historical path & perfornnance broker 43 
is comprised of a path trace handler 80. a path gatherer 
81, an infornrtation register 83. an event & performance 
gatherer 82. a solution provider 84 and a calculation 20 
server 85 all interconnected within the management 
server 10 as follows. The path trace handler 80 is exter- 
nally connected to the request dispatcher 45 and the DB 
manager 46. Also externally connected to the DB man- 
ager 46 is the path gatherer 81 and the event & perform- 25 
ance gatherer 82. The path gatherer 81 is also 
connected to the information register 83, the event & 
performance gatherer 82 and the solution provider 84 
while the event & performance gatherer 82 is also con- 
nected to the calculation server 85. Lastly, in addition to : 30 
being connected to the path gatherer 81, the informa- 
tion register 83 is also externally connected to the queu- 
ing rranager 60. 

[0075] As noted afc>ove, the historical path & per- 
formance broker 43 allows the user to retrieve the his- 35 
torical performance or route data associated with a 
particular route which has been collected and perma- 
nently stored in the database following the execution of 
previous historical route trace requests or historical per- 
formance monitoring requests. In order to do this, the 40 
user initiates a request through tiie GUI 23 specifying a 
particular route and the desired time period for which 
the historical performance data or route data is to be 
retrieved. The user's request is received in the request 
dispatcher 45 which places it into the path trace handler 45 
80. The path trace handler 80 operates to extract from 
the historical retrieval request the specified time period 
and the source and destination endpoint components 
defining the route for which historical data is to be 
retrieved. The path trace har>dler 80 sut>sequently for- so 
wards them to tiie DB manager 46 which then requests 
and captures from the datattase 25 ail the paths associ- 
ated with the specified source and destination endpoint 
corrponents of the specified route for the desired time 
period. 55 
[0076] Once captured from the database 25. the DB • 
manager 46 places the paths into the queuing manager 
60 for procesang. The queuing manager 60 will then 



sequentially send, in accordance with its defined priority 
levels, the patiis queued to the information register 83 
for further processing. The path gatherer 81 then reads 
the paths from the information register 83 and. for each 
path read, requests the event & performance gatherer 
82 to retrieve all associated routing events and perform- 
ance information from the database 25. The event & 
performance gatherer 82 togetiier with the solution pro- 
vider 84 operate to process the data collected from the 
database 25 into a format suited for use by the GUI 23 
through the notification channel 44. 
[0077] Referring now to Figure 1 1 , there is shown a 
second embodimem of the RPM system 20 where a 
MIB 90 is also used to tenrporarily store the routing and 
performance information gatiiered by tiie management 
server 22. In order to store this information, tiie MIB 90 
also has defined the network-level concepts of routes 
and patiis as manageable objects. These routes and 
paths objects can then be accessed by SNMP agents of 
otiier network elements 24 of the IP network 10 or any 
other network entity/application which may benefit from 
that information. The implementation of MIBs such as 
the MIB 90 is well known and is not described here in 
any detail- 

[0078] The RPM system functionality described 
above is implemented in the network manager 1 by pro- 
gramming a general purpose computer (not shown). It is 
understood that the preparation of the programs neces- 
sary to accomplish this RPM functionality is obvious to 
persons of ordinary skilled in the network management 
art. particulariy in view of tiie detailed description of the 
functionality of tiie management server 22 provided 
above in reference to Figures 4 through 9. 
[0079] While the invention has been described 
above with reference to a particular type of network, fur- 
ther modifications and improvements to support other 
types of networks which will occur to those skilled in the 
art. may be made within tiie purview of the appended 
claims, without departing from the scope of the inven- 
tion in its broader aspect. 

[0080] In particular, the invention has been 
described above with respect to an IP. network. It is 
understood XhaX the invention could also be applied to 
other types of networks. Further, the invention is not 
restricted to SNMP networks with an INM management 
platform and couki also be used with manager-agent 
environments different from SNMP and in association 
with other management platfornre. 
[0081 ] The RPM system has been descra^ed atx>ve 
with reference to a particular GUI design. It is to be 
urxJerstood that other GUI designs may also be used to 
enable a GUI user to specify and monitor routes, paths 
and associated interfaces in a network in accordance 
with the present invention. As an exanrrple, the GUI has 
been described above as having a main conputer win- 
dow which is sutxiivided into 5 sections for entering the 
RPM monitoring parameters and viewing the corre- 
sponding RPM results. It is to be understood that tiie 
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conputer window could be subdivided into more or less 
than 5 sections according to the GUI user's specific 
management needs. 

[0082] It is also to be understood that other types of 
user interfaces may be used. For example, a command 
line interface (GLI) could be used. Moreover, the user 
interface has been described as being separate from 
the management server. It is to be understood that if 
necessary, the user interface may also be implemented 
internally to the management server and still fall within 
the purview of the present inverrtion. 



paths, the path trace and nnonitor logic unit is com- 
prised of : 

a trace handler for receiving the at least one 
5 route to monitor; 

a path objects assembler for assembling the 
set of paths associated with the at least one 
route to monitor: and 

a path change monitor logic unit for monitoring 
10 changes in the set of paths associated with the 

at least one route to monitor. 



Claims 

1. A route and path management system for a com- is 
munication network comprising plurality of network 
elements whereby the network elements form mul- 
tiple sets of paths, each set of paths being associ- 
ated with a respective route in the communication 
network, the route and path management compris- 20 
ing: , • 

a data collector for collecting data from the plu- . . 
rality of network elements whereby the data 
collected relates to at least one route and an 25 
associated set of paths formed in the communi- 
cation network: and 

a management server connected to the data 
collector to receive the data collected for moni- 
toring the at least one route and the associated 30 
set of paths formed in the communication net- 
work . ■ 

2. The route and path management system of claim 1 
further conprising a user interface connected to the 35 
management server for specifying the at least one 
route to monitor and reporting the routing perform- 
ance and path changes associated therewith. 



3. The route arxJ path management system of claim 1 40 
or 2, wherein for monitoring the at least one route 
arKi the associated set of paths defined in the com- 
munication network, the managemerrt server is ^ 
conprised of: 

a path trace and monKor logic unit operable to 
receive the at least one route for performing 
historical and real-time monitoring of the path 
changes of the associated set of paths; and 
a perforn^nce monitor logic unit operable to so 
receive the at least one route for monitoring the . 
performance of the at least one route and the 
associated set of paths historically. and in real- . 
time. , . ' . * . 

- • ' • 55 

4. The route and path management system of claim 3 
wherein for performing historical and real-time . * 
monitoring of path changes of the assodated set of 



5. The route and path management system of daim 3 
or 4 wherein for historically monitoring of the per- 
formance of the at least one route and the associ- 
ated set of paths, the performance monitor logic 
unit is comprised of: 

a monitoring queue operable to receive the at 
least one route aind hold identification and per- 
formance data related to the at least one route 
and the associated set of paths; 
an object perfornnance monitor logic unit con- 
nected to the monitoring queue for polling the 
network elements forming the associated set of 
paths for new identification and performance 
data: 

a path performance nrtonrtor logic unit con- 
nected to both the monitoring queue and the 
object performance monitor logic unit for com-> 
puting the performance associated with each 
path of the set of paths; 
a route performance monitor logic unit con- 
nected to both the monitoring queue and the 
path performance monitor logic unit for com- - 
puting the overall performance of the at least 
one route; and 

a threshold crossing logic unit connected to the 
object performance monitor logic unit, the path 
. performance monitor logic unit and the route 
performance monitor logic unit for measuring 
the performance of the at least one route and 
the associated set of paths against suitable 
performance thresholds. 

6. The route and path management system of daim 5 
wherein for monitoring the performance of the at 
least one route and the associated set of. paths in 
real-time, the performance nnonitor logic unit is fur- 
ther comprised:Of : 

an object performance logic unit connected to 
the monitoring qu^e for. polling the network 
elements forming the associated set of paths 
for new identification and performance data; 
a path perfbrnnance logic unit connected to 
both the monitoring queue and the object per- 
formance logic unit for comp'^^ling the perform- 
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ance associated with each path of the set of 
paths; 

a route performance logic unit connected to 
both the monitoring queue and the path per- 
formance logic unit for computing the overall s 
performance of the at least one route. 

The route and path management system of any of 
claims 3 to 6 wherein the mar^gement server fur- 
ther comprises a historical path and performance io 
broker for historically analysing the routing perform- 
ance arxJ the path changes of the at least one route 
and the associated set of paths. 



8. The route and path management system of claim 7 is 
wherein for historically analysing the routing per- 
formance and the path changes of the at least one 
route and the associated set of paths, the historical 
path and performance broker is comprised erf: 

20 

a trace handler for receiving the at least one 
route; 

a path gatherer for retrieving the set of paths 
associated with the at least one route; 
an event and performance gatherer for gather- 2S 
ing the routing performance data and the path 
changes of the at least one route and the asso- 
ciated set of paths: and 
a solution provider for processing the routing 
performance data and the path changes of the so 
at least one route and the associated set of 
paths in a form appropriate for analysis. 

9. The route and path management system of any of 
claims 1 to 8 wherein the data collector is operable 35 
with simple network management protocol (SNMP). 

1 0. The route and path management system of any one 
of claims 2 to 9 wherein the data collector is com- 
prised of a trap gatherer for gathering traps gener- 40 
ated by network elements of the communication 
network. 

1 1 ■ The route and path management system of claim 
10 wherein the management server further has a 45 
trap handler connected to the trap gatherer for han- 
dling the traps generated and notifying the user 
interfece of significant events. 

12. The route and path management system of any so 
preceding claim wherein the route and path man- 
agement system is operable with integrated net- 
work management (INM). 

13. The route and path management system of any of ss 
claims 1 to 12 in combination with a database for 
storing the routing performance results of the at 
least one route arKi the path changes associated 



therewith. 

14. The route and path management system of claim 
13 in combination with a management information 
base for providing SNMP access to the at least one 
route and the associated set of paths monitored. 

15. A route and path management system for a com- 
munication network comprising plurality of network 
elements whereby the network elements form mul- 
tiple sets of paths, each set of patfis being associ- 
ated with a respective route in the communication 
network, the route and path nr^anagement compris- 
ing: 

collecting means for collecting data from the 
plurality of network elements whereby the data 
collected relates to at least one route and an 
associated set of paths formed in the communi- 
cation network; 

managing means connected to the collecting 
means to receive the data collected and opera- 
ble to monitor the at least one route and the 
associated set of paths formed in the communi- 
cation network for determining routing perform- 
ance and path changes of the associated set of 
paths. 

IS. The route and path management system of claim 
15 wherein the managing means comprises: 

means for performing historical and real-time 
monitoring of the path changes of the associ- 
ated set of paths; and 

means for monitoring the performance of the at 
least one route and the associated set of paths 
historically and in real-time. = 

17. The route and pathmanagement system of claim 
15 or 16 further comprising a user interface for. 
reporting routing performance and path changes of 
the associated set of paths. 

18- The route and path management system of claim 
15, 16 or .17, wherein the collecting means com- 
prises a data collector. 

19. The route and path management system of claim 
15. 16 17 or 18, wherein the managing means com- 
prises a management server. 

20. A method for managing routes and paths in a com- 
munication network comprising a plurality of net- 
work elements whereby the network elements form 
multiple sets of paths, each set of paths comprising 
at least one fonvard path and one backward path 
and being associated with a respective route 
defined by a source endpoint and a destination 
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endpoint in the communication network, the 
method comprising the steps of: 

collecting data from the plurality of network ele- 
ments whereby the data collected relates to at 
least one route and an associated set of paths; 
and 

monitoring the at least one route and the asso- 
ciated set of paths. 

21. The method of claim 20 wherein the step of moni- 
toring the at least one route and the associated set 
of paths conrtprises the steps of: 

performing historical and real-time monitoring is 
of the path changes of the associated set of 
paths; and 

monitoring of the performance of the at least 
one route and the associated set of paths his- 
torically and in real-time. 20 

22. The method of claim 21 wherein the step of per- 
forming historical and real-time monitoring of the 
path changes of the associated set of paths com- 
prises the steps of : 25 

assembling each one of the set of paths; and 
monitoring the path changes of the associated 
set of paths historically and in real-time. 

^ 30 

23. The method of daim 22 wherein the step of assem- 
bling each one of the set of paths comprises the 
steps of: - 

at each of the source endpoint and subsequent 35 
intermediate points located between the 
source enc(point and the destination endpoint, 
collecting routing information for assembling 
the at least one fonward p>ath of the set of paths; 
and , 40r 

at each of the destination endpoint and sul>se- 
quent intermediate points located between the 
destination endpoint and the source endpoint, 
collecting routing Information for assenrWing * 
the at least one backward, path of the set of 45 
paths. 
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